Internet Info 1994 March

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / ien / ien-35 < prev next >

Wrap

Text File | 1988-12-01 | 31.8 KB | 892 lines

INDRA Note 674 PSPWN ** IEN 35 SATNET and the Provision of Transnet Service P. T. Kirstein and C. J. Bennett ABSTRACT: This note discusses the problem of providing service to ARPANET from the UK via SATNET after the existing direct ARPANET link disappears. A general approach is outlined. The solution offered attempts to make as much use of current hardware and software as possible. Areas where problems are anticipated, or where insufficient information is available, are indicated. INDRA Research Group Department of Statistics and Computer Science University College London SATNET and the Provision of Transnet Service Page 1 CONTENTS 1. Introduction 2. Overview 2.1 Configuration 2.2 Service Support 2.3 Stages of Development 3. Detailed Requirements 3.1 UCL TIP 3.2 UCL PDP9: Access to EPSS 3.3 UCL PDP-11 3.4 UCL PDP9: Access to X25 3.5 UCL LSI-11 3.6 Gateway LSI-11s 3.7 TCP Service Gateway in the ARPANET 4. Conclusions SATNET and the Provision of Transnet Service Page 2 1. Introduction With the transition of SATNET to a service role and the impending demise of our direct connection to the ARPANET, University College is faced with the problem of how to provide access to the ARPANET for the many UK users who have come to rely on it. There are two aspects to this problem. Users who connect through our site in London must be given terminal access to both ARPANET and EPSS (and possibly the future public PSS, currently due in mid 1979). Other UK users accessing ARPANET through EPSS and ARPANET users accessing EPSS hosts (including the UCL service to Culham, RSRE etc) must be given adequate support at the transport and terminal level to make this possible. Our solution to this must be based on our assessment of the current state of techniques for implementing transnet services. The most significant development in this area has been the development of a number of network-independent protocols. Providing network-independent process-to-process transport service has had the most attention initially. The TCP is the result which is most familiar to members of the ARPANET community. Another network-independent transport protocol is the INWG 96 proposal. There has been a lot of discussion in Europe on protocols for higher level services which are network-independent (beyond the description of basic transport facilities required) and there are several proposals around for virtual terminal protocols, none of which has yet met with general acceptance. Recently the UK Higher Level Protocol Group has published a proposal for a network-independent file transfer protocol, available as INWG Protocol Note 86, which has gained fairly wide approval in the UK and is now being publicised in various international groups. This protocol is a development of the file transfer protocol used on EPSS, and is being implemented on many sites on that network, hence in this document it will be referred to as the EPSS FTP. Ideally, then, we would like to implement our future ARPANET/SATNET/EPSS connection within this context, and assume that connecting lines and machines and providing software to support these network independent protocols is a sufficient solution to the problem. In practise, of course, such an attitude is utopian. It assumes that everyone who wants internet services will adopt network-independent protocols to do it, and they will be perfectly happy to do this themselves. There are some very good practical reasons why this will not happen. Firstly, it means putting a great deal of effort into developing a new solution to a problem which has already been solved. ARPANET users have for many years been using the ARPANET file transfer protocol quite happily, and they are not going to implement a completely different and incompatible one just to enable European users to access their files. Secondly, in order to achieve network-independence, the protocols make the minimal assumptions possible about the nature of the underlying network services, which means that they end up duplicating many aspects of those services. For this reason it is unlikely, for instance, that TCP or INWG 96 will be seen initially as an attractive solution for providing transport services in an X25 environment - much SATNET and the Provision of Transnet Service Page 3 of the emphasis of TCP is on providing end-to-end liaisons in a datagram environment, which many people argue will involve a near duplication of features of the X25 virtual call, to take just one example. Therefore, we foresee the development of transnet services as taking place at a limited number of network sites within the concatenated networks, and it is unlikely that these services will be integrated at any one particular site. A generalised view of the transnet world under this scheme is given in Figure 1. The sites at which the network-independent protocols are implemented have been christened 'service gateways' as they are providing transnet access for particular services. Note that this concept is quite distinct from the gateways which physically connect two networks, providing packet encapsulation, fragmentation, internet routing etc. The service gateways need not stand in any particular physical relationship to each other or to the physical gateways. Clearly there will be strong functional relations between the physical and service gateways, and there is a hierarchy of service gateways. One major research interest of the concept is in establishing just what these functional relations are and how best they should be implemented. While the immediate aim of our network interconnection project is simply to provide communication between the UK and ARPANET through SATNET, the design chosen is one which will facilitate the provision of future services across many networks using the service gateway concept. Section 2 gives an overview of the proposed connection. Section 3 gives a more detailed survey of the software needed in each crucial machine to support the service, relates this survey to our understanding of the existing state of the hardware and software for these machines, and summarises the modifications to existing developments needed to realise the system. Section 4 summarises our main conclusions. SATNET and the Provision of Transnet Service Page 4 Figure 1 - The service gateway concept. SATNET and the Provision of Transnet Service Page 5 2. Overview. 2.1 Configuration The proposed future UCL configuration is given in Figure 2. The principal points to note about this diagram are summarised below. i) The PDP-11, currently the gateway machine, will become a transnet access host on the TIP, connected via the VDH interface currently connected to a PDP9, and probably running under a standard operating system such as UNIX. It will support terminal and file transfer access to and from ARPANET via SATNET through TCP. ii) An alternate route for EPSS-ARPANET traffic will pass through the other PDP9 and the LSI-11 via the X25 connection. The PDP9 will lose its current VDH connection to the TIP. The X25 connection has been so constructed that the LSI will be seen by users as an X25 host; EPSS sees the X25 interface as a process on the PDP9. This LSI will also support TCP to provide access to the ARPANET. iii) The (physical) gateways to SATNET will be replaced by LSI-11s. As indicated, the UCL gateway will have two 1822 interfaces and a VDH interface whereas the gateway on the ARPANET side (presumably the BBN gateway) may only have one 1822 interface. Special hardware for the LSI-11 may be required to handle 50kb on the VDH line across a DMA interface; this will (presumably!) be done by BBN. iv) A transport-level service gateway supporting TCP will terminate the connection on the ARPANET side. This may be a TENEX (or TOPS), or another PDP-11. Further terminal access will be developed via ARPANET Telnet; support for other services, such as transnet file transfer will also be provided at this point. SATNET and the Provision of Transnet Service Page 6 Figure 2 - Proposed UCL Configuration SATNET and the Provision of Transnet Service Page 7 2.2 Service Support The two major service requirements are the provision of terminal access and of file transfer capability. Terminal access requires the mapping of various terminal protocols at the appropriate points, rather like the current SWITCH approach. Mappings between the ARPANET standard Telnet and the TCP-based Telnet will be required in the transport gateway in ARPANET and in the PDP-11 at UCL. The TCP-based Telnet will map into the X25 VPT in the UCL LSI-11, and the ARPA Telnet will map into the EPSS VPT in the PDP9 connected to the TIP. Much of the complexity of this problem comes from linking up two connections when one is being set up by the rather complex procedures of ICP. It is not clear whether TCP-Telnet goes through a similar port-allocation procedure. The situation with regard to FTP is not so clear. The TCP group is intending to implement a TCP-based FTP, but this is still in the planning stages. If this becomes available at the right time, then for service purposes we would perform analogous FTP mappings at the same places. This mapping can be done either on a real-time basis, as we have attempted to do for the EPSS and ARPANET FTPs on our PDP9, or on a staged basis, with the file being stored on some mass-storage device and forwarded to the next stage only when it has all arrived. Based on our past experience, the staged solution is probably preferable when it is possible. The status of the TCP FTP is one of the major question which needs to be followed up. It may not actually be necessary to do a detailed mapping of FTPs in the TCP transport gateways, as both the source and destination of the transfer will be using the standard ARPA FTP. It may only be necessary to map certain low-level features of the FTPs, such as control and data sockets being mapped into TCP ports. This is an option which we should also investigate. If mappings of file transfers have to be done, it is desirable that we keep these to a minimum, and it would be preferable to do them on a large system, such as TENEX. If TCP-based FTPs are to be used, several mappings are involved, none of them on systems of this type. Since in any case it seems that a TCP FTP may not be available in time, an alternative strategy of implementing the EPSS File Transfer Protocol on ARPANET could be adopted. This protocol is specifically designed to be network and transport protocol independent, and so this is an attractive proposition. If transnet file transfer were done this way, this protocol would be implemented in the PDP-11 at UCL, interfacing to both TCP and NCP, and at the transport gateway, interfacing to TCP (or, indeed, at some other site in ARPANET, in which case it would interface to NCP). In this case, the only FTP mapping required is at the site in ARPANET which has the EPSS FTP installed. The transport gateways (i.e. the TCP site in ARPANET, the PDP-11 at UCL, the LSI-11 at UCL, and the PDP9s at UCL) will then be supporting an end-to-end protocol between the FTP service gateway in ARPANET and the destination site in EPSS (or at UCL), and they will perform the classic gateway services of address-mapping, connection-establishment, flow-control, etc. SATNET and the Provision of Transnet Service Page 8 2.3 Stages of Development The work needed for this development will obviously not be done overnight. We see the project taking place in three main stages. i) As much work as possible will be done in the current configuration. Development of software for the PDP-11 at UCL will probably be carried out on a PDP-11 in the ARPANET (exactly which one is to be decided; see sections 3.3 and 3.7). The TCP/X25 LSI-11 will be developed as a terminal host on a local host port on the TIP (see section 3.5). This situation will continue until either the Norway line to ARPANET disappears or LSI-11 gateways are ready. We expect that the direct connection to ARPANET will not disappear before the LSI gateways are ready, and this document is based on that assumption; should events happen otherwise, alternative means of continuing development will have to be found. ii) Once the LSI-gateways are ready and installed, the configuration of Figure 2 can be set up. It is not necessary that both paths become operational at once, but we expect that the TIP-based path will be ready for use at that point, i.e. there will be an operational TCP-based terminal system on the UCL PDP-11. The TCP/X25 LSI-11-based path will be strictly for experimental development at this point, investigating the nature of the connections needed to support the appropriate services. It is not clear whether XNET can be used satisfactorily across SATNET, and any development strategy based on XNET may have to be reconsidered at this point. iii) When the X25/TCP path is ready for service use it will become the main service route between EPSS and ARPA. Either now, or at some other time, the PDP-11 could be directly connected to the LSI-11 gateway, and at some time it will probably support multiple terminals directly. When all these conditions are fulfilled, the TIP could be removed completely. No doubt this possibility will be looked at more closely when the time comes. SATNET and the Provision of Transnet Service Page 9 3. Detailed Requirements This section describes the software needed in the various machines to support the service outlined above. This is done machine by machine. The proposals try to make the minimum changes needed to existing systems or to current plans. Attention is drawn to points on which we need more information, or which we know or believe to be incompletely developed, and also to areas in which problems are expected. 3.1 UCL TIP No functional changes are envisaged for this machine, which will continue to support terminal access as at present. The major change will be updating the routing tables to reflect the absolute isolation the TIP will experience. The major problem which BBN will encounter will be in providing the same remote maintenance and monitoring facilities it has at present. One possibility is to retain the direct lines that ARPA currently maintains to the SIMPs (e.g. the 9.6 kb line between London and Goonhilly), as this is the simplest way to provide direct access to our isolated TIP. However, this is a problem for forces beyond our control. 3.2 UCL PDP9 Access to EPSS No major functional modifications to the existing SWITCH system are expected here for providing terminal-level access. Other services can be set up as concatenated terminal streams. If the EPSS File Transfer Protocol is adopted for transnet service, this will be sufficient to provide an adequate. If not, then the current EPSS FTP/ARPA FTP mapping will be used. The resulting configuration is shown in Figure 3. There is some question as to how much work the full PDP9 system can support simultaneously. If serious overloading occurs, some of the special systems supported (e.g. the Culham link) may be removed from the standard system; if even this is inadequate, then the position of the FTP facilities may be reconsidered. SATNET and the Provision of Transnet Service Page 10 Figure 3 - Terminal Access to EPSS via the PDP9 3.3 UCL PDP-11 The PDP-11 is the first machine considered which will require significant effort to bring up. Much of the new software required has either already been developed or is currently under development by BBN, notably TCP, TCP-Telnet, and these can be run under ELF, which we at UCL have some experience with. ELF has some disadvantages as an operating system to support user services, however. The principal one is that, to the best of our knowledge, it does not support either the NCP or the standard ARPA FTP. This point should be checked. The lack of an FTP would be unimportant if the EPSS File Transfer Protocol is adopted; however the lack of adequate NCP facilities is critical. Also, we would prefer to use an operating system with terminal drivers capable of handling multiple users, as we ultimately expect to be using this machine as a terminal concentrator to replace the TIP. The main new item which has to be tackled in this system is providing a connection between NCP-based Telnet sockets and TCP-Telnet ports. As a gateway between two transport protocols (TCP and NCP) this machine will also have to handle the usual readdressing, flow control and reassembly problems handled by gateways. The configuration under consideration is illustrated in Figure 4. The existing local host interface will not be used, and connection to the TIP will be via the VDH, as the two local host ports on the TIP are taken up by the PDP9 gateway to EPSS and the LSI-11 gateway to SATNET. The looped nature of the traffic may create some unusual flow control problems when there are heavy traffic rates. For this reason, when the file transfer facilities are developed for this machine, onward transfer to EPSS will be done in a staged fashion, with the file being temporarily stored on the RK05 disc. SATNET and the Provision of Transnet Service Page 11 Since we have not been directly involved with the work, one major question on which we lack hard facts is the question of choosing an appropriate operating system. As we have indicated, ELF does not seem to be suitable for a major service role of the kind implied here. The major PDP-11 operating systems that seem to be suitable, both because the expertise is available in the department and because TCP developments are taking place on them are UNIX and RSX-11M. TCP version 2.5s have been developed by BBN under UNIX and ELF; version 3 of TCP is currently being developed by DTI under UNIX and by CCA under RSX-11M. The only system under which a TCP-Telnet seems to be developing is ELF. Further information must be obtained about these points. Two other points are relevant here. The first is that it would be highly desirableable to be able to use the same operating system here as we do on the remote transport gateway (see section 3.7) if this is to be a PDP-11; this would considerably speed up the development of the whole system. Secondly, we have to investigate the cross-net loading facilities. The great advantage of ELF is the fact that it is specifically tailored to run with XNET. With other operating systems we will almost certainly require a special bootstrap to be able to use XNET at all, and it is unlikely that we will be able to use its full facilities even then. For debugging purposes this is not so serious, but for cross-net loading it is vital. Figure 4 - PDP-11 Configuration 3.4 UCL PDP9 - Access to X25 Here, the anticipated course is that the current system will develop along its existing lines, with the complete excision of the current ARPANET software. For transnet communication an EPSS user will access the X25 port, which will also support incoming connections from ARPANET. The present SWITCH system running on this machine, supporting SATNET and the Provision of Transnet Service Page 12 the EPSS VPT and FTP, will be the standard system on the PDP9 which is connected to the TIP. Both Level 2 and Level 3 of X25 are currently available, and although it is designed basically as a DCE we anticipate no great difficulty in turning it into a DTE if required. This point, however, requires more detailed study. Calls coming in from EPSS will automatically be forwarded to the LSI-11 if no EPSS address is included in the data field. In the reverse direction, calls being forwarded to EPSS will require an EPSS address in the data field, but these must be provided by the LSI-11. This scheme fits into the current context very well, and we see no reason not to retain it. Figure 5 - UCL PDP9 - X25 Access 3.5 UCL LSI-11 Essentially, this machine will consist of an X25 terminal and a TCP terminal connecting an HDLC interface on the one side to a BBN 1822 interface on the other through a number of mapping modules. The basic structure is shown in Figure 6. The X25 hardware for this configuration has recently been completed, and the 1822 interface is nearly ready. The software, however, is in a rather more uncertain state, and it is expected that this terminal will remain an experimental link for some time. As with the PDP-11, it is not clear what operating system this machine will use, although the alternatives are fewer: either the current TCP terminal, available under MOS, is altered to run under RSX-11, or the current X25 terminal, available under RSX-11, is altered to run under MOS. RSX-11 will support development in a high-level language (RTL2), but it is doubtful whether this is advantageous, as the generated code is large. Also, whichever system used will initially have to support crossnet loading (and possibly development) of the TCP-terminal software. This question is an unknown for both systems, and urgently needs resolution. SATNET and the Provision of Transnet Service Page 13 The TCP side of the terminal is based on the packet-radio TCP terminal developed at SRI. The major difference is the replacement of the DSP, which is packet-radio dependent, by an XNCP-like module for communication with the gateway. This raises two problems. The first is the unorthodox nature of the 1822 connection, in that neither side of the HOST/IMP interface supports what would normally be understood as an IMP. There is, however, a precedent for this situation, as COMSAT has built a similarly non-standard connection between its 360 and its PDP-11 gateway, so we should be able to consult them for guidance for potential problems. Moreover, 1822 is a highly symmetric interface, so major problems are not anticipated. The second problem is that this module will initially only support a single TCP port, whereas there is a strong requirement for supporting several ports for different services. However, creating a multiplexing 'XNCP' is not the whole solution to the problem, as we will then be able to support several TCP connections only if they go to different hosts. Unfortunately, we need to support several connections to one particular host (i.e. the remote transport gateway in ARPANET - see section 3.7). This will require modifications to the TCP itself. Our current X25 is written in RTL2 or in assembler versions derived from it, and is rather large in its RTL2 version. The VPT is a larger RTL2 program. While the generated assembly code is believed not to be highly system dependent, this aspect has not been analysed in detail - the driver for the HDLC chip is a particularly important question here. On the face of it, therefore, it would seem to be easier to put X25 under MOS than to put TCP (written in MACRO) under RSX-11 from the point of view of aiding development. The RTL2 code has been written so that it can be run as both as X25 DTE and a DCE, and one problem under investigation concerns deciding when it should be one or the other. A study of the incorporation of the X25 software into MOS should be undertaken very soon. Finally, there is the connection between the X25 side and the TCP side. At this stage, it is not possible to say much more about this than to state the functional requirements. Terminal access will require a mapping between the X25-VPT and the TCP-Telnet; this will undoubtedly be based on our experience with similar problems in the PDP9 SWITCH systems. File transfer may also need to be mapped, and will certainly require support of high-throughput connections on both sides; the evolution of suitable strategies to match the flow will have to be evolved. These modules will also have to solve the questions of forward addressing and routing. In the service gateway context, these functions become more important than the mappings. The question of how this code is to be developed has still not been satisfactorily resolved. There are two main options. The first is to develop it in our PDP-11, using XNET to load in the system. This requires a MOS-based VDH driver for a DMA interface, which is currently being written. The second option is to load the LSI-11 directly, using one of our local host ports on the TIP. This requires the completion of the 1822 interface, which is proceeding rapidly. Other options, such as storing the software on floppy discs, are basically variants of these. SATNET and the Provision of Transnet Service Page 14 Figure 6. UCL LSI-11: TCP Access Configuration 3.6 Gateway LSI-11s No special role is envisaged for these gateways, as end-to-end transport is being provided entirely by TCP at this point. It is not clear how far development on LSI-11 gateways has progressed, as opposed to PDP-11 gateways; this is a question which must raised with BBN. One problem that may well affect the schedule is that our preliminary calculations suggest that access to the VDH line will have to be via a DMA interface if high throughput is desired and the machine is not to spend up to 50% of its time servicing interrupts from the interface. Critical questions for this machine, then, are the development of MOS-drivers for DMA VDH interfaces, and the ability of the gateway to handle more than two nets - the 'nets' here being SATNET, the TCP/NCP PDP-11, and the TCP/X25 LSI-11. It is conceivable, if TCP develops concepts of selecting grades of service from local nets, that we may become interested in developing our ideas in these gateways as well as the ones already discussed, but this does not seem to be on the current schedule of TCP development and in any case would have to be coordinated very closely with BBN. SATNET and the Provision of Transnet Service Page 15 Figure 7 - UCL SATNET Gateway Configuration 3.7 TCP Service Gateway in the ARPANET Finally, a site in the ARPANET must be selected to provide the far end of the TCP pipeline. The development needed here is very similar to that discussed in section 3.3, and developing both ends simultaneously on PDP-11s under the same operating system, as we did for GNOME, could speed up the process considerably. However, the system support and system resources we could draw on are likely to be limited unless coupled with a TENEX. Differences between the two sites will emerge at later stages in the development. These will be mainly connected with addressing and routing problems: this machine will act as a service site for the whole US ARPANET, whereas the UCL PDP-11 will only service EPSS traffic through the PDP9. The other alternative is to use a TENEX or TOPS-20 system for this end of the connection, as TCP and TCP-Telnet are both available, and they have proved and extensive resources for such work. However, this will mean developing two versions of the new software, and will also involve experimenting with special versions of standard software (such as ARPA-Telnet, FTP, NCP) which may lead to organisational problems, as these are machines supporting large user populations. This question will again have to be gone into more deeply. SATNET and the Provision of Transnet Service Page 16 Figure 8 - TCP Service Gateway Configuration SATNET and the Provision of Transnet Service Page 17 4. Conclusions In this note future ARPANET service is considered from several points of view. Firstly, there is the problem of providing UCL users with terminal access to ARPANET via SATNET. Secondly, access has to be provided between EPSS and ARPANET for a variety of services. Initially, this will be of the terminal mapping type already in use, but the design proposed has hooks for extension towards a more sophisticated concept of supporting service gateways. Where possible, the scheme uses existing systems, or systems already under development. Obviously, there will be problems in modifying these to meet the new requirements, but the scheme outlined has attempted to minimise these, and at the very least to identify them. Integration of the various components into a unified system requires most software work at the points where various layers of trsnsport protocol terminate and have to be connected to the next level. The two most critical points for providing a general transnet transport service are in the TCP service gateway in ARPANET and the TCP/X25 LSI-11 at UCL. A similar critical point occurs in the PDP-11 at UCL. The PDP9 giving terminal access to EPSS from UCL is not critical as this problem has already been solved. Again, a solution for the transport connection between the EPSS Bridge and X25 is already in existence to the point where the LSI-11 will be seen as a host on EPSS when it is connected to the PDP9. Specific areas where we anticipate difficulties with existing software are: the remote loading (and debugging) of non-ELF operating systems for the PDP-11; the choice of an operating system for the LSI-11; the nonstandard nature of the 1822 interface connecting this machine to the gateway LSI-11; the use of XNET across SATNET; and the provision of a DMA VDH interface on the gateway LSI-11s, to connect them to SATNET. Areas on which we need further information include: the status of TCP and TCP-Telnet under various standard PDP-11 operating systems; the current status (or even the existence!) of the TCP-FTP; the current status of LSI-11 gateways; and information that we can get about activities such as the non-standard 1822 connections which have been undertaken by other groups. In short, the components required to connect UCL and EPSS to ARPANET via SATNET are on the whole either already in existence or already under development. The new work is in sticking them together in such a way as to provide adequate transnet service.